Computer graphics is the art and science of generating pictures, images, or other graphical or pictorial information with a computer. Generation of the pictures or images is commonly called rendering. Generally, in three-dimensional (3D) computer graphics, geometry that represents surfaces (or volumes) of objects in a scene is translated into pixels (picture elements), stored in a frame buffer, and then displayed on a display device.
One challenge involves determining how to share a cache memory (herein, also referred to simply as a cache or memory). For instance, depth and/or texture processing can be determined at an application level by a central processing unit (CPU), at the front end of a graphics processor (e.g., by a vertex shader program generating texture type data maps), or can be implemented in a post-processing manner (e.g., by pixel shader generation of post image rendered in a frame buffer). In light of the varied locations of modules utilized for these and other types of processes, it is evident that access (either read or writes) to a cache can be shared. For instance, referring to the example data processing system 10 shown in FIG. 1, a controller 20 (e.g., software module) provides commands (or equivalently, instructions) to a pipeline comprising an upstream processing unit P1 12, an intermediary processing unit P2 14, and a downstream processing unit P3 16. Each unit, P1-P3, comprises one or more registers (not shown) that receive the respective command(s) for the individual unit while passing commands that have no relevance to the particular unit to the next unit. Both P1 12 and P3 16 share a cache 18, and either P1 12 or P3 16 can access data in the cache 18 when enabled or activated by a respective enable command received through the pipeline from the controller 20. In other words, access to the cache 18 is preferably implemented by one of the active processing units P1 12 or P3 16 in response to a command provided by the controller 20 to avoid read-after write (RAW) hazards.
Thus, in one implementation, the controller 20 (or driver software) may provide an enable command directed to P3 16, which passes from P1 12, through P2 14, to eventually enable P3 16. Similarly, the controller 20 may send a disable command to P1 12, which results in the de-activating or disabling of P1 12 currently in process. When this switching occurs from P1 12 to P3 16, since commands pass through the pipeline from P1 12 to P3 16, there is no risk of P3 16 not receiving any task after P1 12 is idle, and thus no synchronization mechanisms are needed. In other words, operations in P1 12 cease by the time P3 16 receives, through the pipeline, an enabling command in one of its registers (not shown). However, there is a risk that data stored in the cache 18 may be lost if switching occurs in the opposite direction (i.e., from P3 16 to P1 12), since P1 12 may receive an enabling command in one of its registers (not shown) from the controller 20 before a disabling command reaches P3 16 through the pipeline.